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Abstract 
This document describes a framework for IP Flow Information Export 
(IPFIX) Mediation. This framework extends the IPFIX reference model 
specified in RFC 5470 by defining the IPFIX Mediator components. 
Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6183. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
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described in the Simplified BSD License. 
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Les 


Introduction 


The IP Flow Information Export (IPFIX) architectural components in 
[RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating 
using the IPFIX protocol. Due to the sustained growth of IP traffic 
in heterogeneous network environments, this Exporter-Collector 
architecture may lead to scalability problems. In addition, it does 
not provide the flexibility required by a wide variety of measurement 
applications. A detailed descriptions of these problems is given in 
[RFC5982]. 


To fulfill application requirements with limited system resources, 
the IPFIX architecture needs to introduce an intermediate entity 
between Exporters and Collectors. From a data manipulation point of 
view, this intermediate entity may provide the aggregation, 
correlation, filtering, and modification of Flow Records and/or 
Packet Sampling (PSAMP) Packet Reports to save measurement system 
resources and to perform preprocessing tasks for the Collector. From 
a protocol conversion point of view, this intermediate entity may 
provide conversion into IPFIX, or conversion of IPFIX transport 
protocols (e.g., from UDP to the Stream Control Transmission Protocol 
(SCTP)) to improve the export reliability. 


This document introduces a generalized concept for such intermediate 
entities and describes the high-level architecture of IPFIX 
Mediation, key IPFIX Mediation architectural components, and 
characteristics of IPFIX Mediation. 


This document is structured as follows: Section 2 describes the 
terminology used in this document, Section 3 gives an IPFIX/PSAMP 
document overview, Section 4 describes a high-level reference model, 
Section 5 describes functional features related to IPFIX Mediation, 
Section 6 describes combinations of components along with some 
application examples, Section 7 describes consideration points of the 
encoding for IPFIX Message Headers, Section 8 describes the 
Information Elements used in an IPFIX Mediator, and Section 9 
describes the security issues raised by IPFIX Mediation. 


Terminology and Definitions 


The IPFIX-specific and PSAMP-specific terminology used in this 
document is defined in [RFC5101] and [RFC5476], respectively. The 
IPFIX-Mediation-specific terminology used in this document is defined 
in [RFC5982]. However, as reading the problem statements document is 
not a prerequisite to reading this framework document, the 
definitions have been reproduced here along with additional 
definitions. In this document, as in [RFC5101] and [RFC5476], the 
first letter of each IPFIX-specific and PSAMP-specific term is 
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capitalized along with the IPFIX-Mediation-specific terms defined 
here. The use of the terms "must", "should", and "may" in this 
document is informational only. 


In this document, we use the term "record stream" to mean a stream of 
records carrying flow-based or packet-based information. The records 
may be encoded as IPFIX Data Records or in any other format. 


Transport Session Information 


The Transport Session Information contains information that allows 
the identification of an individual Transport Session as defined 
in [RFC5101]. If SCTP is used as transport protocol, the 
Transport Session Information identifies the SCTP association. If 
TCP or UDP is used as transport protocol, the Transport Session 
Information corresponds to the 5-tuple {Exporter IP address, 
Collector IP address, Exporter transport port, Collector transport 
port, transport protocol}. The Transport Session Information may 
include further details about how Transport Layer Security (TLS) 
[RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347] is 
used for encryption and authentication. 


Original Exporter 


An Original Exporter is an IPFIX Device that hosts the Observation 
Points where the metered IP packets are observed. 


IPFIX Mediation 


IPFIX Mediation is the manipulation and conversion of a record 
stream for subsequent export using the IPFIX protocol. 


The following terms are used in this document to describe the 
architectural entities used by IPFIX Mediation. 


Intermediate Process 


An Intermediate Process takes a record stream as its input from 
Collecting Processes, Metering Processes, IPFIX File Readers, 
other Intermediate Processes, or other record sources; performs 
some transformations on this stream based upon the content of each 
record, states maintained across multiple records, or other data 
sources; and passes the transformed record stream as its output to 
Exporting Processes, IPFIX File Writers, or other Intermediate 
Processes in order to perform IPFIX Mediation. Typically, an 
Intermediate Process is hosted by an IPFIX Mediator. 
Alternatively, an Intermediate Process may be hosted by an 
Original Exporter. 
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Specific Intermediate Processes are described below. However, this 
is not an exhaustive list. 


Intermediate Conversion Process 


An Intermediate Conversion Process is an Intermediate Process that 
transforms non-IPFIX into IPFIX or manages the relation among 
Templates and states of incoming/outgoing transport sessions in 
the case of transport protocol conversion (e.g., from UDP to 
SCTP). 


Intermediate Aggregation Process 


An Intermediate Aggregation Process is an Intermediate Process 
that aggregates records based upon a set of Flow Keys or functions 
applied to fields from the record (e.g., data binning and subnet 
aggregation). 


Intermediate Correlation Process 


An Intermediate Correlation Process is an Intermediate Process 
that adds information to records, noting correlations among them, 
or generates new records with correlated data from multiple 
records (e.g., the production of bidirectional flow records from 
unidirectional flow records). 


Intermediate Selection Process 


An Intermediate Selection Process is an Intermediate Process that 
selects records from a sequence based upon criteria-evaluated 
record values and passes only those records that match the 
criteria (e.g., filtering only records from a given network to a 
given Collector). 


Intermediate Anonymization Process 


An Intermediate Anonymization Process is an Intermediate Process 
that transforms records in order to anonymize them, to protect the 
identity of the entities described by the records (e.g., by 
applying prefix-preserving pseudonymization of IP addresses). 


IPFIX Mediator 


An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation 
by receiving a record stream from some data sources, hosting one 
or more Intermediate Processes to transform that stream, and 
exporting the transformed record stream into IPFIX Messages via an 
Exporting Process. In the common case, an IPFIX Mediator receives 
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a record stream from a Collecting Process, but it could also 
receive a record stream from data sources not encoded using IPFIX, 
e.g., in the case of conversion from the NetFlow V9 protocol 
[RFC3954] to the IPFIX protocol. 


Note that the IPFIX Mediator is a generalization of the concentrator 
and proxy elements envisioned in the IPFIX requirements [RFC3917]. 
IPFIX Mediators running appropriate Intermediate Processes provide 
the functionality specified therein. 


3. IPFIX/PSAMP Documents Overview 


IPFIX Mediation can be applied to flow-based or packet-based 
information. The flow-based information is encoded as IPFIX Flow 
Records by the IPFIX protocol, and the packet-based information is 
extracted by some packet selection techniques and then encoded as 
PSAMP Packet Reports by the PSAMP protocol. Thus, this section 
describes relevant documents for both protocols. 


CRSA IPFIX Documents Overview 


The IPFIX protocol [RFC5101] provides network administrators with 
access to IP Flow information. The architecture for the export of 
measured IP Flow information from an IPFIX Exporting Process to a 
Collecting Process is defined in [RFC5470], per the requirements 
defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how 
IPFIX Data Records and Templates are carried via a number of 
transport protocols from IPFIX Exporting Processes to IPFIX 
Collecting Processes. IPFIX has a formal description of IPFIX 
Information Elements, their names, types, and additional semantic 
information, as specified in [RFC5102]. The IPFIX Management 
Information Base is defined in [RFC5815]. Finally, [RFC5472] 
describes what types of applications can use the IPFIX protocol and 
how they can use the information provided. Furthermore, it shows how 
the IPFIX framework relates to other architectures and frameworks. 
The storage of IPFIX Messages in a file is specified in [RFC5655]. 


3.2. PSAMP Documents Overview 


The framework for packet selection and reporting [RFC5474] enables 
network elements to select subsets of packets by statistical and 
other methods and to export a stream of reports on the selected 
packets to a Collector. The set of packet selection techniques 
(Sampling and Filtering) standardized by PSAMP is described in 
[RFC5475]. The PSAMP protocol [RFC5476] specifies the export of 
packet information from a PSAMP Exporting Process to a Collector. 
Like IPFIX, PSAMP has a formal description of its Information 
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Elements, their names, types, and additional semantic information. 
The PSAMP information model is defined in [RFC5477]. The PSAMP 
Management Information Base is described in [PSAMP-MIB]. 


IPFIX Mediation Reference Model 


Figure A shows the high-level IPFIX Mediation reference model as an 
extension of the IPFIX reference model presented in [RFC5470]. This 
figure covers the various possible scenarios that can exist in an 
IPFIX measurement system. 
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Figure A: IPFIX Mediation Reference Model Overview 
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The functional components within each entity are indicated within 
brackets []. An IPFIX Mediator receives IPFIX Flow Records or PSAMP 
Packet Reports from other IPFIX Mediators, IPFIX Flow Records from 
IPFIX Original Exporters, PSAMP Packet Reports from PSAMP Original 
Exporters, and/or a record stream from other sources. The IPFIX 
Mediator then exports IPFIX Flow Records and/or PSAMP Packet Reports 
to one or multiple Collectors and/or other IPFIX Mediators. 


Figure B shows the basic IPFIX Mediator component model. An IPFIX 
Mediator contains one or more Intermediate Processes and one or more 
Exporting Processes. Typically, it also contains a Collecting 
Process but might contain several Collecting Processes, as described 
in Figure B. 


IPFIX (Data Records) 


| | 

| | 

e os | 

---------------------- +--------------------, | 

| Exporting Process (es) [7 
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| | | | 
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o a ¡| 

| | Intermediate Process (es) [5 | 
FA E EERE ea A A ee anes oe Doneen A INN r 

| | | | 

oe plot | 

pr ee ene iH 

| | Collecting Process (es) Lat 
ac aia IN IA AA A DENA EN EE eh a aed Sa es ee r 

| leee EEE dl | 


IPFIX (Data Records) 
Figure B: Basic IPFIX Mediator Component Model 


However, other data sources are also possible: an IPFIX Mediator can 
receive a record stream from non-IPFIX protocols such as NetFlow 
[RFC3954] exporter(s). This document does not make any particular 
assumption on how a record stream is transferred to an IPFIX 
Mediator. Figure C shows the IPFIX Mediator component model in the 
case of IPFIX protocol conversion from non-IPFIX exporters. 
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IPFIX (Data Records) 


+------------------------ | - | --------------------- + 
| IPFIX Mediator | | 
—— [-+------------------- | 
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| | Exporting Process (es) ES 
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| record stream 
4+------------------------ | ----------------------- + 
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Packets coming into observation points 


Figure C: IPFIX Mediator Component Model in IPFIX 
Protocol Conversion 


Alternatively, an Original Exporter may provide IPFIX Mediation by 
hosting one or more Intermediate Processes. The component model in 
Figure D adds Intermediate Process(es) to the IPFIX Device model 
illustrated in [RFC5470]. In comparison with Figures 1 or 2 in 
[RFC5470], the Intermediate Process is located between Exporting 
Process(es) and IPFIX or PSAMP Metering Process(es). 
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IPFIX (Data Records) 
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Packets coming into Observation Points 
Figure D: IPFIX Mediation Component Model at Original Exporter 
In addition, an Intermediate Process may be collocated with an IPFIX 


File Reader and/or Writer. Figure E shows an IPFIX Mediation 
component model with an IPFIX File Writer and/or Reader. 
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with IPFIX File Writer/Reader 
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5x IPFIX Mediation Functional Blocks 


Figure F shows a functional block diagram example in an IPFIX 
Mediator that has different Intermediate Process types. 
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Figure F: IPFIX Mediation Functional Block Diagram 
5.1. Collecting Process 


A Collecting Process in an IPFIX Mediator is not different from the 
Collecting Process described in [RFC5101]. Additional functions in 
an IPFIX Mediator include transmitting the set of Data Records and 
Control Information to one or more components, i.e., Intermediate 
Processes and other applications. In other words, a Collecting 
Process may duplicate the set and transmit it to one or more 
components in sequence or in parallel. In the case of an IPFIX 
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Mediator, the Control Information described in [RFC5470] includes 
IPFIX Message Header information and Transport Session Information 
along with information about the Metering Process and the Exporting 
Process in an Original Exporter, e.g., Sampling parameters. 


5.2. Exporting Process 


An Exporting Process in an IPFIX Mediator is not different from the 
Exporting Process described in [RFC5101]. Additional functions in an 
IPFIX Mediator may include the following: 


o Receiving the trigger to transmit the Template Withdrawal Messages 
from Intermediate Process(es) when relevant Templates become 
invalid due to, for example, incoming session failure. 


o Transmitting the origin (e.g., Observation Point, Observation 
Domain ID, Original Exporter IP address, etc.) of the data in 
additional Data Record fields or additional Data Records. The 
parameters that represent the origin should be configurable. 


5.3. Intermediate Process 


An Intermediate Process is a key functional block for IPFIX 
Mediation. Its typical functions include the following: 


o Generating a new record stream from an input record stream 
including context information (e.g., Observation Domain ID and 
Transport Session Information) and transmitting it to other 
components. 


o Reporting statistics and interpretations for IPFIX Metering 
Processes, PSAMP Metering Processes, and Exporting Processes from 
an Original Exporter. See Section 4 of [RFC5101] and Section 6 of 
[RFC5476] for relevant statistics data structures and 
interpretations, respectively. Activation of this function should 
be configurable. 


o Maintaining the configurable relation between Collecting 
Process (es) /Metering Process (es) and Exporting Process (es) /other 
Intermediate Process(es). 


o Maintaining database(s) of Data Records in the case of an 
Intermediate Aggregation Process and an Intermediate Correlation 
Process. The function has the Data Record expiration rules 
described in the next subsection. 


o Maintaining statistics on the Intermediate Process itself, such as 
the number of input/output Data Records, etc. 
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o Maintaining additional information about output record streams, 
which includes information related to the Original Exporters, 
Observation Domain, and administrative domain as well as some 
configuration parameters related to each function. 


In the case of an Intermediate Aggregation Process, Intermediate 
Anonymization Process, and Intermediate Correlation Process, the 
value of the "flowKeyIndicator" needs to be modified when modifying 
the data structure defined by an original Template. 


For example, an Intermediate Aggregation Process aggregating incoming 
Flow Records composed of the sourcelPv4Address and 
destinationIPv4Address Flow Keys into outgoing Flow Records with the 
destinationIPv4Address Flow Key must modify the incoming 
flowKeyIndicator to contain only the destinationIPv4Address. 


5.3.1. Data Record Expiration 


An Intermediate Aggregation Process and Intermediate Correlation 
Process need to have expiration conditions to export cached Data 
Records. In the case of the Metering Process in an Original 
Exporter, these conditions are described in [RFC5470]. In the case 
of the Intermediate Process, these conditions are as follows: 


o If there are no input Data Records belonging to a cached Flow for 
a certain time period, aggregated Flow Records will expire. This 
time period should be configurable at the Intermediate Process. 


o If the Intermediate Process experiences resource constraints 
(e.g., lack of memory to store Flow Records), aggregated Flow 
Records may prematurely expire. 


o For long-running Flows, the Intermediate Process should cause the 
Flow to expire on a regular basis or on the basis of an expiration 
policy. This periodicity or expiration policy should be 
configurable at the Intermediate Process. 


In the case of an Intermediate Correlation Process, a cached Data 
Record may be prematurely expired (and discarded) when no correlation 
can be computed with newly received Data Records. For example, an 
Intermediate Correlation Process computing one-way delay may discard 
the cached Packet Report when no other matching Packet Report are 
observed within a certain time period. 


5.3.2. Specific Intermediate Processes 


This section describes the functional blocks of specific Intermediate 
Processes. 
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5.3.2.1. Intermediate Conversion Process 


When receiving a non-IPFIX record stream, the Intermediate Conversion 
Process covers the following functions: 


o Determining the IPFIX Information Element identifiers that 
correspond to the fields of the non-IPFIX records (e.g., 
converting the NetFlow V9 protocol [RFC3954] to the IPFIX 
Information Model [RFC5102]). 


o Transforming the non-IPFIX records into Data Records, (Options) 
Template Records, and/or Data Records defined by Options 
Templates. 


o Converting additional information (e.g., sampling rate, sampling 
algorithm, and observation information) into appropriate fields in 
the existing Data Records or into Data Records defined by new 
Options Templates. 


IPFIX transport protocol conversion can be used to enhance the export 


reliability, for example, for data retention and accounting. In this 
case, the Intermediate Conversion Process covers the following 
functions: 


o Relaying Data Records, (Options) Template Records, and Data 
Records defined by Options Templates. 


o Setting the trigger for the Exporting Process in order to export 
IPFIX Template Withdrawal Messages relevant to the Templates when 
Templates becomes invalid due to, for example, incoming session 
failure. This case applies to SCTP and TCP Transport Sessions on 
the outgoing side only. 


o Maintaining the mapping information about Transport Sessions, 
Observation Domain IDs, and Template IDs on the incoming and 
outgoing sides in order to ensure the consistency of scope field 
values of incoming and outgoing Data Records defined by Options 
Templates and of Template IDs of incoming and outgoing IPFIX 
Template Withdrawal Messages. 


5.3.2.2. Intermediate Selection Process 


An Intermediate Selection Process has analogous functions to the 
PSAMP Selection Process described in [RFC5475]. The difference is 
that the Intermediate Selection Process takes a record stream, e.g., 
Flow Records or Packet Reports, instead of observed packets as its 
input. 
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The typical function is property match filtering that retrieves a 
record stream of interest. The function selects a Data Record if the 
value of a specific field in the Data Record equals a configured 
value or falls within a configured range. 


5.3.2.3. Intermediate Aggregation Process 


An Intermediate Aggregation Process covers the following functions: 


o 


Merging a set of Data Records within a certain time period into 
one Flow Record by summing up the counters where appropriate. 


Maintaining statistics and additional information about aggregated 
Flow Records. 


The statistics for an aggregated Flow Record may include the 
number of original Data Records and the maximum and minimum values 
of per-flow counters. Additional information may include an 
aggregation time period, a new set of Flow Keys, and observation 
location information involved in the Flow aggregation. 

Observation location information can be tuples of (Observation 
Point, Observation Domain ID, Original Exporter IP address) or 
another identifier indicating the location where the measured 
traffic has been observed. 


Aggregation of Data Records, which can be done in the following 
ways: 


* Spatial composition 


With spatial composition, Data Records sharing common 
properties are merged into one Flow Record within a certain 
time period. One typical aggregation can be based on a new set 
of Flow Keys. Generally, a set of common properties smaller 
than an original set of Flow Keys results in a higher level of 
aggregation. Another aggregation can be based on a set of 
Observation Points within an Observation Domain, on a set of 
Observation Domains within an Exporter, or on a set of 
Exporters. 


If some fields do not serve as Flow Keys or per-Flow counters, 
their values may change from Data Records to Data Records 
within an aggregated Flow Record. The Intermediate Aggregation 
Process determines their values by the first Data Record 
received, a specific Exporter IP address, or other appropriate 
decisions. 
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Furthermore, a new identifier indicating a group of observation 
locations can be introduced, for example, to indicate PoPs 
(Points of Presence) in a large network, or a logical interface 
composed of physical interfaces with link aggregation. 


* Temporal composition 


With temporal composition, multiple Flow Records with identical 
Flow Key values are merged into a single Flow Record of longer 
Flow duration if they arrive within a certain time interval. 
The main difference to spatial composition is that Flow Records 
are only merged if they originate from the same Observation 
Point and if the Flow Key values are identical. For example, 
multiple Flow Records with a Flow duration of less than one 
minute can be merged into a single Flow Record with more than 
ten minutes Flow duration. 


In addition, the Intermediate Aggregation Process with temporal 
composition produces aggregated counters while reducing the 
number of Flow Records on a Collector. Some specific non-key 
fields, such as the minimumIpTotalLength/maximumIpTotalLength 
or minimumTTL/maximumTTL, will contain the minimum and maximum 
values for the new aggregated Flow. 


Spatial and temporal composition can be combined in a single 
Intermediate Aggregation Process. The Intermediate Aggregation 
Process can be combined with the Intermediate Selection Process in 
order to aggregate only a subset of the original Flow Records, for 
example, Flow Records with small numbers of packets as described 
in Section 6.2. 


5.3.2.4. Intermediate Anonymization Process 


An Intermediate Anonymization Process covers the following typical 
functions: 


o 


Deleting specified fields 


The function deletes existing fields in accordance with some 
instruction rules. Examples include hiding network topology 
information and private information. In the case of feeding Data 
Records to end customers, disclosing vulnerabilities is avoided by 
deleting fields, e.g., "ipNextHopIP{v4|v6}Address", 

"bgpNextHopIP (v4|v6)Address", "bgp(Next |Prev}AdjacentAsNumber", 
and "mplsLabelStackSection", as described in [RFC5102]. 
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o Anonymizing values of specified fields 


The function modifies the values of specified fields. Examples 
include anonymizing customers’ private information, such as IP 
address and port number, in accordance with a privacy protection 
policy. The Intermediate Anonymization Process may also report 
anonymized fields and the anonymization method as additional 
information. 


5.3.2.5. Intermediate Correlation Process 


An Intermediate Correlation Process can be viewed as a special case 
of the Intermediate Aggregation Process, covering the following 
typical functions: 


o Producing new information including metrics, counters, attributes, 
or packet property parameters by evaluating the correlation among 
sets of Data Records or among Data Records and other meta data 
after gathering sets of Data Records within a certain time period. 


o Adding new fields into a Data Record or creating a new Data 
Record. 


A correlation of Data Records can be done in the following ways, 
which can be implemented individually or in combinations. 


o One-to-one correlation between Data Records, with the following 
examples: 


* One-way delay, Packet delay variation in [RFC5481] 
The metrics come from the correlation of the timestamp value on 
a pair of Packet Reports indicating an identical packet at 
different Observation Points in the network. 


* Packet inter-arrival time 
The metrics come from the correlation of the timestamp value on 
consecutive Packet Reports from a single Exporter. 


* Rate-limiting ratio, compression ratio, optimization ratio, 
etc. 
The data values come from the correlation of Data Records 
indicating an identical Flow observed on the incoming/outgoing 
points of a WAN interface. 
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o Correlation amongst Data Records, with the following examples: 


* Bidirectional Flow composition 
The method of exporting and representing a Bidirectional Flow 
(Biflow) is described in [RFC5103]. The Bidirectional Flow 
composition is a special case of Flow Key aggregation. The 
Flow Records are merged into one Flow Record as Biflow if Non- 
directional Key Fields match and the Directional Key Fields 


match their reverse direction counterparts. The direction 
assignment method to assign the Biflow Source and Destination 
as additional information may be reported. In the case of an 


Intermediate Aggregation Process, the direction may be assigned 
arbitrarily (see [RFC5103], Section 5.3). 


* Average/maximum/minimum for packets, bytes, one-way delay, 
packet loss, etc. 
The data values come from the correlation of multiple Data 
Records gathered in a certain time interval. 


o Correlation between Data Record and other meta data 


Typical examples are derived packet property parameters described 
in [RFC5102]. The parameters are retrieved based on the value of 
the specified field in an input Data Record, compensating for 
traditional exporting devices or probes that are unable to add 
packet property parameters. Typical derived packet property 
parameters are as follows: 


*  "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] 
This value indicates the egress router of a network domain. It 
is useful for making a traffic matrix that covers the whole 
network domain. 


* BGP community attributes 
This attribute indicates tagging for routes of geographical and 
topological information and source types (e.g., transit, peer, 
or customer) as described in [RFC4384]. Therefore, network 
administrators can monitor the geographically-based or source- 
type-based traffic volume by correlating the attribute. 


* "mplsVpnRouteDistinguisher" described in [RFC5102] 
This value indicates the VPN customer’s identification, which 
cannot be extracted from the core router in MPLS networks. 
Thanks to this correlation, network administrators can monitor 
the customer-based traffic volume even on core routers. 
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6. Component Combination 


An IPFIX Mediator may be able to simultaneously support more than one 
Intermediate Process. Multiple Intermediate Processes generally are 
configured in the following ways. 


o Parallel Intermediate Processes 
A record stream is processed by multiple Intermediate Processes in 
parallel to fulfill the requirements of different applications. 
In this setup, every Intermediate Process receives a copy of the 


entire record stream as its input. 


o Serial Intermediate Processes 


To execute flexible manipulation of a record stream, the 
Intermediate Processes are connected serially. In that case, an 
output record stream from one Intermediate Process forms an input 
record stream for a succeeding Intermediate Process. 


In addition to the combination of Intermediate Processes, the 
combination of some components (Exporting Process, Collecting 
Process, IPFIX File Writer and Reader) can be applied to provide 
various data reduction techniques. This section shows some 
combinations along with examples. 


6.1.  Data-Based Collector Selection 


The combination of one or more Intermediate Selection Processes and 
Exporting Processes can determine to which Collector input Data 
Records are exported. Applicable examples include exporting Data 
Records to a dedicated Collector on the basis of a customer or an 
organization. For example, an Intermediate Selection Process selects 
Data Records from a record stream on the basis of the peering 
autonomous system number, and an Exporting Process sends them to a 
dedicated Collector, as shown in the Figure G. 
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| Intermediate | | Exporting | 
| Selection Process 1 | Process 1 
+--+--- Peering AS #10 ---+--> +--> Collector 1 
| A EN E NA AAA , PST , 
record | | Intermediate | | Exporting | 
stream | | Selection Process 2 | | Process 2 | 
------- Te Peering AS #20 ---+-->| +--> Collector 2 
T oii cs oe a E IAEA T VAS a a li a £ 
I Spas e a a ee : 
| | Intermediate | | Exporting | 
| | Selection Process 3 | | Process 3 | 
+--+--- Peering AS #30 ---+-->| +--> Collector 3 


Figure G: Data-Based Collector Selection 
6.2. Flow Selection and Aggregation 


The combination of one or more Intermediate Selection Processes and 
Intermediate Aggregation Processes can efficiently reduce the amount 
of Flow Records. The combination structure is similar to the concept 
of the Composite Selector described in [RFC5474]. For example, an 
Intermediate Selection Process selects Flows consisting of a small 
number of packets and then transmits them to an Intermediate 
Aggregation Process. Another Intermediate Selection Process selects 
other Flow Records and then transmits them to an Exporting Process, 
as shown in Figure H. This results in aggregation on the basis of 
the distribution of the number of packets per Flow. 


| Intermediate | 
Selection 
Process 1 
-+ packetDeltaCount +-> 
l 


Intermediate | 


| Exporting | 
| Aggregation 

| 

| 


Process 


Process 


<= 5. | 


Intermediate 
Selection 


| 
| | Process 2 | 
++ pagketDeltacount -===2=====5=-=HSH=H== > 
| Fae 
r 


Figure H: Flow Selection and Aggregation Example 
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6.3. IPFIX File Writer/Reader 


An IPFIX File Writer [RFC5655] stores Data Records in a file system. 
When Data Records include problematic Information Elements, an 
Intermediate Anonymization Process can delete these fields before the 
IPFIX File Writer handles them, as shown in Figure I. 


Collecting Intermediate IPFIX 
IPFIX Process Anonymization File 
----- > | +->| Process +->| Writer | 


Figure I: IPFIX Mediation Example with IPFIX File Writer 


In contrast, an IPFIX File Reader [RFC5655] retrieves stored Data 
Records when administrators want to retrieve past Data Records from a 
given time period. If the data structure of the Data Records from 
the IPFIX File Reader is different from what administrators want, an 
Intermediate Anonymization Process and Intermediate Correlation 
Process can modify the data structure, as shown in Figure J. 


| IPFIX | | Intermediate | | Intermediate | | Exporting | 
| File | | Anonymization | | Correlation | | Process | 
| Reader +->| Process +->| Process +->| 


Figure J: IPFIX Mediation Example with IPFIX File Reader 

In the case where distributed IPFIX Mediators enable on-demand export 
of Data Records that have been previously stored by a File Writer, a 
collecting infrastructure with huge storage capacity for data 
retention can be set up. 

7. Encoding for IPFIX Message Header 
The IPFIX Message Header [RFC5101] includes Export Time, Sequence 
Number, and Observation Domain ID fields. This section describes 
some consideration points for the IPFIX Message Header encoding in 
the context of IPFIX Mediation. 
Export Time 


An IPFIX Mediator can set the Export Time in two ways. 


* Case 1: keeping the field value of incoming Transport Sessions 
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* Case 2: setting the time at which an IPFIX Message leaves the 
IPFIX Mediator 


Case 1 can be applied when an IPFIX Mediator operates as a proxy 
at the IPFIX Message level rather than the Data Record level. In 
case 2, the IPFIX Mediator needs to handle any delta timestamp 
fields described in [RFC5102], such as 
"flowStartDeltaMicroseconds" and "flowEndDeltaMicroseconds". 


Sequence Number 


In the case where an IPFIX Mediator relays IPFIX Messages from one 
Transport Session to another Transport Session, the IPFIX Mediator 
needs to handle the Sequence Number properly. In particular, the 
Sequence Number in the outgoing session is not allowed to be re- 
initialized, even when the incoming session shuts down and 
restarts. 


Observation Domain ID 


According to [RFC5101], the Observation Domain ID in the IPFIX 
Message Header is locally unique per Exporting Process. In 
contrast to the Observation Domain ID used by an Original 
Exporter, the Observation Domain ID used by an IPFIX Mediator does 
not necessarily represent a set of Observation Points located at 
the IPFIX Mediator itself. 


An IPFIX Mediator may act as a proxy by relaying entire IPFIX 
Messages. In this case, it may report information about the 
Original Exporters by using the Observation Domain ID of the 
outgoing Messages as the scope field in an Options Template 
Record. 


Otherwise, the IPFIX Mediator should have a function to export the 
observation location information regarding the Original Exporter. 
The information contains the IP addresses and Observation Domain 
IDs used by the Original Exporters and some information about the 
Transport Session, for example, the source port number, so that 
different Exporting Processes on the same Original Exporter can be 
identified. As far as privacy policy permits, an IPFIX Mediator 
reports the information to an IPFIX Collector. 


If information about a set of Original Exporters needs to be 
reported, it can be useful to export it as Common Properties as 
specified in [RFC5473]. The commonPropertiesID may then serve as 
a scope for the set of Original Exporters. The Common Properties 


Kobayashi, et al. Informational [Page 23] 


RFC 


Kob 


6183 IPFIX Mediation: Framework April 2011 


Withdrawal Message [RFC5473] can be used to indicate that an 
incoming Transport Session from one of the Original Exporters was 
closed. 


Information Model 


IPFIX Mediation reuses the general information models from [RFC5102] 
and [RFC5477], and, depending on the Intermediate Processes type, 
potentially Information Elements such as: 


o Original Exporter IP address, Observation Domain ID, and source 
port number about the Transport Session at the Original Exporter, 
in the case where an IPFIX Mediator reports original observation 
location information in Section 7. The Information Elements 
contained in the Export Session Details Options Template in 
[RFC5655] may be utilized for this purpose. 


o Report on the applied IPFIX Mediation functions as described in 
Section 6.7. in [RFC5982]. 


o Certificate of an Original Exporter in Section 9. The Information 
Element exporterCertificate in [RFC5655] may be utilized for this 
purpose. 


Security Considerations 


As Mediators act as both IPFIX Collecting Processes and Exporting 
Processes, the Security Considerations for IPFIX [RFC5101] also apply 
to Mediators. The Security Considerations for IPFIX Files [RFC5655] 
also apply to IPFIX Mediators that write IPFIX Files or use them for 
internal storage. In addition, there are a few specific 
considerations that IPFIX Mediator implementations must take into 
account. 


By design, IPFIX Mediators are "men-in-the-middle": they intercede in 
the communication between an Original Exporter (or another upstream 
Mediator) and a downstream Collecting Process. TLS provides no way 
to connect the session between the Mediator and the Original Exporter 
to the session between the Mediator and the downstream Collecting 
Process; indeed, this is by design. This has important implications 
for the level of confidentiality provided across an IPFIX Mediator 
and the ability to protect data integrity and Original Exporter 
authenticity across a Mediator. In general, a Mediator should 
maintain the same level of integrity and confidentiality protection 
on both sides of the mediation operation, except in situations where 
the Mediator is explicitly deployed as a gateway between trusted and 
untrusted networks. 
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Subsequent subsections deal with specific security issues raised by 
IPFIX Mediation. 

9.1. Avoiding Security Level Downgrade 
An IPFIX Mediator that accepts IPFIX Messages over a Transport 


Session protected by TLS [RFC5246] or DTLS [RFC4347] and that then 
exports IPFIX Messages derived therefrom in cleartext is a 


potentially serious vulnerability in an IPFIX infrastructure. The 
concern here is that confidentiality protection may be lost across a 
Mediator. 


Therefore, an IPFIX Mediator that receives IPFIX Messages from an 
upstream Exporting Process protected using TLS or DTLS must provide 
for sending of IPFIX Messages resulting from the operation of the 
Intermediate Process(es) to a downstream Collecting Process using TLS 
or DTLS by default. It may be configurable to export records derived 
from protected records in cleartext but only when application 
requirements allow. 


There are two common use cases for this. First, a Mediator 
performing a transformation that leads to a reduction in the required 
level of security (e.g., by removing all information requiring 
confidentiality from the output records) may export records 
downstream without confidentiality protection. Second, a mediator 
that acts as a proxy between an external (untrusted) network and an 
internal (trusted) network may export records without TLS when the 
additional overhead of TLS is unnecessary (e.g., on a physically 
protected network in the same locked equipment rack). 


9.2. Avoiding Security Level Upgrade 


There is a similar problem in the opposite direction: as an IPFIX 
Mediator’s signature on a TLS session to a downstream Collecting 
Process acts as an implicit assertion of the trustworthiness of the 
data within the session, a poorly deployed IPFIX Mediator could be 
used to "legitimize" records derived from untrusted sources. 
Unprotected sessions from the Original Exporter are generally 
untrusted, because they could have been tampered with or forged by an 
unauthorized third party. The concern here is that a Mediator could 
be used to add inappropriate trust to external information whose 
integrity cannot be guaranteed. 


When specific deployment requirements allow, an IPFIX Mediator may 
export signed IPFIX Messages containing records derived from records 
received without integrity protection via TLS. One such deployment 
consideration would be the reverse of the second case above: when the 
Mediator acts as a proxy between an internal (trusted) and an 
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external (untrusted) network and when the path from the Original 
Exporter is protected using some other method and the overhead of a 
TLS session is unnecessary. 


In such cases, the IPFIX Mediator should notify the downstream 
Collector about the missing protection of all or part of the original 
record stream as part of the Transport Session Information. 


9.3. Approximating End-to-End Assertions for IPFIX Mediators 


Because the Transport Session between an IPFIX Mediator and an 
Original Exporter is independent from the Transport Session between 
the Mediator and the downstream Collecting Process, there is no 
existing method via TLS to assert the identity of the original 
Exporting Process downstream. However, an IPFIX Mediator, which 
modifies the stream of IPFIX Messages sent to it, is by definition a 
trusted entity in the infrastructure. Therefore, the IPFIX 
Mediator's signature on an outgoing Transport Session can be treated 
as an implicit assertion that the Original Exporter was positively 
identified by the Mediator and that the source information it 
received was trustworthy. However, as noted in the previous section, 
IPFIX Mediators must in this circumstance take care not to provide an 
inappropriate upgrade of trust. 


If the X.509 certificates [RFC5280] used to protect a Transport 
Session between an Original Exporter and an IPFIX Mediator are 
required downstream, an IPFIX Mediator may export Transport Session 
Information, including the exporterCertificate and the 
collectorCertificate Information Elements, with the Export Session 
Details Options Template defined in Section 8.1.3 of [RFC5655] or the 
Message Details Options Template defined in Section 8.1.4 of 
[RFC5655] in order to export this information downstream. However, 
in this case, the IPFIX Mediator is making an implicit assertion that 
the upstream session was properly protected and therefore trustworthy 
or that the Mediator has otherwise been configured to trust the 
information from the Original Exporter and, as such, must protect the 
Transport Session to the downstream Collector using TLS or DTLS as 
well. 


9.4. Multiple Tenancy 


Information from multiple sources may only be combined within a 
Mediator when that Mediator is applied for that specific purpose 


(e.g., spatial aggregation or concentration of records). In all 
other cases, an IPFIX Mediator must provide for keeping traffic data 
from multiple sources separate. Though the details of this are 


application-specific, this generally entails separating Transport 
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Sessions within the Mediator and associating them with information 
related to the source or purpose, e.g., network or hardware address 
range, virtual LAN tag, interface identifiers, and so on. 
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